IN THE UNITED STATES 
PATENT AND TRADEMARK OFFICE 
PATENT APPLICATION 

HARDENED VOYAGE DATA RECORDER 



This application claims the benefit of 
Provisional Application serial number 60/277,029 filed 
March 19, 2001, the complete disclosure of which is 
10 hereby incorporated by reference herein. 



BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

15 The invention relates to apparatus for 

recording data regarding the operation of a sea borne 
vessel. More particularly, the invention relates to 
apparatus for recording and protecting data leading up to 
an accident or "incident". 

20 

2 . Brief Description of the Prior Art 

It has long been noted that the investigation 
of maritime accidents and incidents could benefit from 
the recording of data and audible commands occurring 
25 aboard ships. Indeed, many considered this an inevitable 
technological extension of the time-honored ship's 
logbook. This desire has culminated in the development 
of an international standard governing the performance of 
a Voyage Data Recorder (VDR) . 



In 1974 the Safety of Life at Sea (SOLAS) 
Convention of the International Maritime Organization 
5 (IMO) acknowledged the value and expressed the desire of 
having recorders on ships similar to the "black box" 
flight recorders for aircraft. This began a long process 
of establishing international standards and requirements 
for a Voyage Data Recorder (VDR) . 

10 

In 1996, VDR requirements, which had been 
debated for a long time, began to emerge in the 
navigation and electronics subgroup (NAV) of the IMO. 
Anticipating an eventual IMO resolution concerning VDRs, 

15 lEC (International Electrotechnical Commission) TC80 
formed WGii, which began structuring a specification 
based on preliminary drafts of the NAV requirements. The 
IMO passed resolution A. 861 (20) in November 1997 and the 
lEC standard 6199 6 was completed as a Committee Draft for 

20 Voting in March 1999. The specification was published in 
August 2 000. 



The lEC 61996 Ship borne Voyage Data Recorder 
Performance Requirements describes data acquisition and 
storage functions and refers to a "protective capsule" 
and a "final storage medium". Architecture for complying 
with this standard has emerged with two major components. 



2 



In the first component, the ship's interfaces, 
data acquisition, and soft recording functions are 
encompassed in a Data Management Unit (DMU) . The DMU is 
5 intended for installation in the relatively benign 

environment of the bridge. The second component is the 
Hardened Voyage Recorder (HVR) which encompasses the 
protective capsule and final storage medium. The HVR is 
designed for survivability and recoverability . It is 
10 intended for external installation on the bridge deck or 
on top of the superstructure. 



The primary function of the Hardened Voyage 
Recorder (HVR) is to protect the data acquired by the 
15 Voyage Data Recorder (VDR) so that the data can be used 
during accident or "incident" investigation. 



SUMMARY OF THE INVENTION 

20 

It is therefore an object of the invention to 
provide a Hardened Voyage Recorder which meets or exceeds 
the requirements of the lEC 61996 test specifications, 
for the protective capsule and final storage medium. 

25 

It is also an object of the invention to 
provide a Hardened Voyage Recorder which has a 
substantial storage capacity. 



It is another object of the invention to 
provide a Hardened Voyage Recorder which is capable of 
recording radar data, audio, and other sensor data. 

5 It is yet another object of the invention to 

provide a Hardened Voyage Recorder which has a long life 
and low operating power. 

It is another object of the invention to 
10 provide a Hardened Voyage Recorder which is easy to 
install and service. 

It is still another object of the invention to 
provide a Hardened Voyage Recorder which easily 
15 interfaces with one or more DMUs. 

In accord with these objects which will be 
discussed in detail below, the Hardened Voyage Recorder 
(HVR) according to the invention includes two separable 
20 subassemblies. 

The first subassembly is a mounting base 
subassembly designed to be directly fastened to the ship 
and provide a watertight cable entry for power and data 
25 connections. 
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The second subassembly is a removable hardened 
memory subassembly which is attached to the mounting base 
with a quick releasing clamp. The hardened memory 
5 subassembly has a bracket for an externally mounted 

underwater location beacon with dual activation moisture 
sensors to avoid inadvertent activation due to spray, 
rain, or hosing off. The HVR is preferably painted a 
highly visible florescent orange with white reflective 
10 labels. The reflective labels contain the required text: 
VOYAGE DATA RECORDER, DO NOT OPEN, REPORT TO AUTHORITIES. 



The mounting base subassembly includes 
electronics for receiving data and writing data to the 
15 memory in the hardened memory subassembly. 

According to the presently preferred 
embodiment, the power connection accepts either 110/220 
VAC or 2 4 VDC and the data connection is an ETHERNET 
20 connection. The AC and DC power connections may both be 
active at the same time. The AC connection is preferably 
used during normal conditions and the DC connection is 
preferably coupled to the ship's UPS (uninterrupted power 
supply) . 



25 



Further, according to the presently preferred 
embodiment, the HVR receives data via TCP/IP (terminal 
connection protocol/ internet protocol) over ETHERNET. 
The HVR is therefore assigned an IP address and is 
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configurable via a "web browser". This also enables the 
formation of a network of multiple HVRs all coupled to 
numerous sensors via the ETHERNET network. 

The removable hardened memory subassembly 
preferably includes 1,5 gigabytes of solid state memory 
which is protected in a "boiler" such as that disclosed 

in co-owned, co-pending application serial number — / 

' filed — / — / — , the complete disclosure of which is 
hereby incorporated herein by reference. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a perspective view of an HVR 
according to the invention; 

FIG. 2 is a side elevation view of an HVR 
according to the invention; 

FIG. 3 is a top view of an HVR according to the 

invention ; 

FIG. 4 is a perspective view of the hardened 
memory subassembly with the beacon bracket removed; 



FIG. 5 is a perspective view of the mounting 
base subassembly; 



FIG. 6 is a side elevation view of the hardened 
memory subassembly with the beacon bracket removed; 



5 FIG. 7 is a sectional view taken along line A-A 

in FIG. 6; 

FIG. 8 is a sectional detail of the encircled 
area of FIG. 2 ; 

10 

FIG. 9 is a side elevation view of the mounting 
base subassembly; 

FIG. 10 is a sectional view taken along line 
15 B-B of FIG. 9; 

FIG. 11 is a plan view of the mounting base 
subassembly; 

20 FIG. 11a is a perspective view of a stacked 

memory boards including memory interface converter chips; 

FIG. 12 is a sample "screen shot" of the HVR 
"home page" ; 

25 

FIG. 13 is a sample screen shot of the HVR 
login page ; 
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FIG. 14 is a sample screen shot of the HVR 
network setup page; and 

FIG. 15 is a sample screen shot of the HVR 
device update page. 

DETAILED DESCRIPTION 

Turning now to Figures 1-3, the Hardened Voyage 
Recorder (HVR) lo according to the invention includes two 
separable subassemblies. The first subassembly 12 is a 
mounting base subassembly designed to be directly 
fastened to the ship and provide a watertight cable entry 
for power and data connections. The second subassembly 
14 is a removable hardened memory subassembly which is 
attached to the mounting base with a quick releasing 
clamp. 

Referring now to the mechanical features of the 
subassembly 12, as shown in Figures 1-3, the mounting 
base subassembly 12 has a lower flange 16 defining three 
mounting holes 18, 20, 22. Two cable connectors 24, 26 
are provided for a watertight coupling of power and data 
cables (not shown) . As seen best in Figures 2 and 8-10, 
the subassembly 12 is also provided with an lower flange 
28 which is used to provide a sealing engagement with the 
removable hardened memory subassembly 14. As seen best 
in Figure 8, the upper flange 28 is provided with two 



concentric grooves 30, 32 which are adapted to receive 
gasket 34 and o-ring 36. 36 is preferably a rubber 
o-ring for moisture protection. 34 is preferably a wire 
mesh for EMI protection. 

The mechanical features of the hardened memory 
subassembly 14 include a bracket 38 for an externally 
mounted underwater location beacon 40. The beacon is 
preferably provided with dual activation moisture sensors 
to avoid inadvertent activation due to spray, rain, or 
hosing off. The subassembly 14 also has two lifting 
handles 42, 44 and an upper flange 46 which is used to 
provide a sealing engagement with the subassembly 12 as 
seen best in Figures 2 and 8. 

As shown in Figure 1, the HVR also includes a 
V-band 48 having two quick release clamps 50, 52. As 
mentioned above, the HVR is preferably painted a highly 
visible florescent orange with white reflective labels, 
e.g. label 54 shown in Figures 1 and 2. The reflective 
labels contain the required (by lEC 61996) text: VOYAGE 
DATA RECORDER, DO NOT OPEN, REPORT TO AUTHORITIES. A 
strip of reflective tape, 19, is shown in FIG. 1, further 
satisfying the requirements of lEC 61996. 

The presently preferred embodiment of the HVR 
10 is approximately thirteen inches high and has a 
diameter of approximately eight inches. The lower flange 
16 of the subassembly 12 is substantially triangular and 



is approximately ten inches per side. The total weight 
of the HVR is approximately forty one pounds with the 
base 12 weighing approximately thirteen pounds and the 
memory subassembly 14 weighing approximately twenty eight 
5 pounds. 

Before turning to the electronic and software 
specifications of the subassembly 12, it should be noted 
that the subassembly 14 includes memory 56 which is 
10 protected in a "boiler" 58 such as that disclosed in 

previously incorporated application serial number — / 



According to the presently preferred 
15 embodiment, electronic access to the memory 56 is 

provided by a ribbon cable 60 having a (preferably JIG) 
connector 62. The memory is preferably a stacked memory 
such as that disclosed in previously incorporated 

application serial number — / , or in U.S. Patent 

20 Number 5,9 69,953, the complete disclosure of which is 

incorporated by reference herein. More particularly, the 
memory is preferably of the type utilizing "BGA" 
packaging (ball grid array packages) as memory 
components . 

25 

Referring now to Figures 5 and 9-11, the 
mounting base subassembly 12 includes electronics 
(partially shown as 64 and 66 in Figures 9 and 10) for 
receiving data and writing data to the memory in the 
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hardened memory subassembly 14 . 

According to the presently preferred 
embodiment, the power connection is provided by a 
5 terminal strip 68 which accepts either 110/220 VAC or 24 
VDC or both. The data connection is an ETHERNET 
connection which is provided by either an RJ-45 connector 
70 or an optional ETHERNET terminal block 72. The AC and 
DC power connections may both be active at the same time. 
10 The AC connection is preferably used during normal 

conditions and the DC connection is preferably coupled to 
the ship's UPS (uninterrupted power supply). The 
maximum power consumption is preferably fifteen watts. 

15 According to the presently preferred 

embodiment, the stepped down and bridge rectified AC 
feeds the same storage capacitor that is fed through a 
diode by the DC, so the higher voltage at the anodes will 
provide the operating current. lEC 61996 paragraph 4.5.3 

20 requires a two hour reserve uninterrupted power source 
(UPS) . 

When connecting the ship's UPS system to the 
HVR, either the AC or DC input may be used. Clearly the 
25 negative terminal of the capacitor and the primary side 
of the switching power supply are grounded to the DC 
return. If AC is the only power wired, a IK Ohm resistor 
ties this input ground to the AC safety ground. The 
primaries of the AC input transformer can be strapped in 
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parallel for 115 Vrms or in series for 230 Vrms by means 
of jumpers on the terminal board (not shown) . 

The memory is operated by the DC power from the 
5 secondary of the switching transformer, and is isolated 
from the AC and DC power lines. A secondary ground, 
which is connected to the case and the ETHERNET shield, 
must be tied to the hull to prevent voltage difference 
that could induce corrosion. As shown in FIG. 11, 
10 according to a preferred embodiment of the invention, a 
ground pad 74 is used for grounding. A notch 76 in the 
upper flange 28 of the subassembly 12 is used to prevent 
pressure differential in a deep sea pressure environment. 

15 Those skilled in the art will appreciate that 

the ETHERNET cabling should be shielded to protect it 
from the expected intense RF fields generated by other 
shipboard eguipment such as radar. The foil shield 
should end as close as possible to the case after it has 

20 passed through the sealing connector 26. The shield's 

drain wire connects to the ground pad 74 which is located 
about one inch from the connector 26. Keeping the shield 
as short as possible inside the case prevents it from re- 
radiating externally induced signals by using the case as 

25 a voltage node. The drain wire at the other end of the 
ETHERNET cable (at the DMU) should also be grounded to 
the ship's hull. 



12 



As mentioned above, according to the presently 
preferred embodiment, the memory used in the subassembly 
14 is BGA memory. Accordingly, the circuits in the 
subassembly 14 include one or more MICs (memory interface 
converter chips) needed to interface (convert between) 
parallel communications which BGA chips employ and the 
serial communications path with processor. The MICs need 
to be able to drive the large number of BGA chips 
distributed in the preferred stacked memory. The MICs 
may be located on the circuit board 1101 shown in Figure 
lla (MIC chips 1102 and 1103) and/or may be distributed 
among the memory circuit boards shown in Figure lla. The 
processor communicates with the MICs to address memory 
and the MICs determine which board or stack contains the 
addressed memory. 

Further, as mentioned above, according to the 
presently preferred embodiment, the HVR receives data via 
TCP/IP (terminal connection protocol/internet protocol) 
over ETHERNET. The HVR is therefore assigned an IP 
address and is configurable via a "web browser". This 
also enables the formation of a network of multiple HVRs 
all coupled to numerous sensors via the ETHERNET network. 

Figures 12-15 illustrate a sample interface to 
the HVR accessible with any web browser coupled to the 
ETHERNET network to which the HVR is coupled. Those 
skilled in the art will appreciate that the ship's 



ETHERNET network could be connected to the Internet via a 
satellite link, thus making the HVR available from 
anywhere in the world. 

5 Figure 12 shows a sample HVR homepage. The 

default URL of the homepage is 192.168.0.2 which is pre- 
set at the factory but which can be changed as shown in 
Figure 14. The homepage Main Menu, provides the main 
entry point to HVR system configuration setup via a web 
10 browser and provides the links for the configuration 

options. In addition links are available that describe 
the HVR Interface Details, HVR System Maintenance, and 
HVR System Information. 

15 The "Network Setup" link shown in Figure 12 

links to the web page shown in Figure 14 providing a 
network hostname and IP address setup data entry form. 

The "Flash Setup" link shown in Figure 12 links 
20 to a web page shown in Figure 15 providing a memory 
partition setup data entry form. 

The "Sys Maintenance" link shown in Figure 12 
links to a web page (not shown) listing the existing 
25 Flash Memory Setup. 

The "Sys Information" link shown in Figure 12 
links to a web page (not shown) providing specific HVR 
software and IP address information. 
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The "Set Password" link shown in Figure 12 
links to a web page (not shown) providing a password 
setup data entry form. 

5 

The "HVR Interface" link shown in Figure 12 
links to a web page (not shown) providing HVR system 
interface information. 

10 The main menu shown in Figure 12 can be 

accessed without entering a password, but in order to 
change any HVR system configurations, a password is 
required to be entered via the password entry page shown 
in Figure 13. In particular, a password is required to 

15 access the Network Setup, Flash Setup, and Set Password 
pages. Access to any of these pages times out when idle 
for 3 00 seconds (which is configurable as shown in Figure 
14) and a password must be re-entered to continue with 
HVR setup modifications. 

20 

The Login Screen of Figure 13 will appear no 
matter which system configuration button is selected 
first. 

25 The HVR is shipped from the factory with the 

following default IP settings: 

IP address: 192.168.0.2 
Subnet Mask: 255.255.255.0 
Default Gateway IP: 192.168.0.1 
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Those skilled in the art will appreciate that 
these are the default settings commonly used with "web- 
accessible" devices. The " 192 . 168 . x . x" IP address scheme 
is part of a "reserved" block of addresses intended 
strictly for networks that are not connected to the 
Internet. When using addresses of this type, the host 
computer must be configured to an address in this range 
in order to "see" the HVR and access the HVR's Web pages. 

By selecting the Network Setup link in Figure 
12, the user is taken to the page shown in Figure 13 
reguiring a password entry. The default password for the 
HVR is "L3HVR". Upon entering the correct password, the 
user will be taken to the page shown in Figure 14 where 
the network parameters can be set as reguired. Changes 
made will not take effect until the HVR is powered down 
and back up. Once the settings have been made, the HVR 
can be connected to the VDR network where it should 
respond at the configured IP address. 

Using the page shown in Figure 15, the user can 
modify or set up the memory areas used for data storage 
on the HVR. Each of these areas or partitions require 
that two parameters be specified: the partition size and 
the partition name. This page shows the number of 
currently available memory devices as well as the per 
device size in Kilobytes. The user partitions and 
allocates the HVR memory data storage from the available 
device pool. The configuration of the memory areas 
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requires that the user specify the size of each memory 
partition in device units, expressed as the number of 
devices to be allocated to that memory area. The 
partition size is thus the device size multiplied by the 
number of devices. 

The HVR system internally allocates devices 
from its internal free pool of devices in order to fill 
the request. The partition configuration request is 
processed starting with partition 0 (ZERO) and proceeding 
to partition 9 (NINE) . The partition allocations cannot 
exceed the number of available devices. Partition 
allocations are processed until all available devices 
have been allocated. 

The partition name is required during the 
actual recording of data into a partition. The 
partition/stream name is to be used by the client 
application wishing to establish a data connection to the 
HVR for the storage of data to a particular partition. 
The connection set up for a data stream requires the 
partition name. The VDR must use the same partition 
(stream) name established during the HVR memory 
configuration in order to establish communication with 
that partition (stream) . 
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Once the HVR has been configured, it appears to 
the outside world as a smart interface to a "pool" of 
nonvolatile memory. Application programs running on one 
5 or more data acquisition systems coupled to the ship's 
network can utilize the pre-allocated memory partitions 
for storage and retrieval purposes. Each stream 
partition is treated as a virtual storage loop in which 
new data continuously overwrites the oldest data in the 
10 partition. The HVR processor keeps track of the current 
write location in the virtual loop for each partition and 
preserves this through power cycles in nonvolatile 
storage. 

15 In order to store data in a previously 

allocated partition, or retrieve data from such a 
partition, software on the client acquisition system must 
"open" a TCP/IP Socket Connection to the Data Acquisition 
Server in the HVR. This Server accepts Socket 

20 Connections at Port 5000 of the IP Address assigned to 

the HVR. Once a connection has been made to the HVR Data 
Acquisition Server, the acquisition software sends a 
command which identifies the target partition and the 
requested operation. The partition is identified by 

25 using the name that was specified for the stream during 
the configuration of the memory pool. 
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The partition stream can be opened for read or 
write access, or to request "write status" information. 
Once the socket connection has been established, and the 
appropriate command issued, data is sent or received over 
the Socket Connection. The HVR Data Acquisition Server 
will accept simultaneous socket connections from multiple 
client processes as well as multiple socket connections 
from a single client process. This automatically results 
from the Client-Server model of the "Berkely Software 
Distribution" socket interface that is used by the HVR. 
There are, however, some limitations imposed by the HVR 
software itself. 

Specifically, there can be only one active 
"Write" client connection associated with a particular 
Stream Partition. The HVR does, however, support 
simultaneous reading from Partitions while writing. The 
"status query" is supported on a Stream regardless of 
whether or not there is an active "Read" or "Write" 
connection on that partition. 

The application layer above TCP/IP is the 
functional interface between a client data acquisition 
subsystem and the HVR. It is assumed that the lower 
protocol layers ensure error-free and timely delivery of 
messages in both directions. Furthermore, an ETHERNET 
HVR interface with TCP/IP layers does not rule out 
multiple concurrent Users of the HVR. Bandwidth of the 
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storage media and communications channels are, of course, 
issues which must be considered at the system level. 

All messages sent to the HVR begin with a 
5 single byte message length value. This represents the 
number of bytes (characters) in the remainder of the 
message. For example, the message for opening a 
partition named "VDR_Radar" for writing would consist of 
a byte value of OxOB (11 characters in the remainder of 

10 the message) , followed by the ASCII characters: 

WVDR_Radar, followed by a Null terminator (byte value 
0x00) . Note that the Partition Name, "VDR_Radar" is a 
9 — character ASCII sequence which is to be followed by a 
Null terminator character. Along with the 'W character 

15 (for writing) that precedes the Partition Name, the total 
length of the message is 11 characters. There should be 
no additional spaces within the message. The "count" byte 
can be thought of as a specification of exactly how many 
more characters will be following in order to complete 

20 the message. Since the "count" specification is a single 
byte, the maximum message length is 2 55 characters. 

Certain HVR messages can include one or more 
optional arguments. In all cases the optional arguments 
25 follow the Null terminator of the base message string. 
Each argument is, itself, a Null — terminated ASCII 
string. Numerical values contained in optional arguments 
are ASCII decimal strings. An example of an optional 
argument which includes a decimal value would be one 
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which limits the amount of data to be sent by the HVR in 
response to the "Read from Stream" command. 

In this case, the added argument might be the 
5 string "X25". The 'X' character indicates that this is 
the "Xfer Count" (transfer count) argument, and the "25" 
is a two — character ASCII — decimal value which represents 
25 Mbytes. The "X25" string represents four additional 
bytes of the complete command (there must be a Null 

10 terminator) , and would be so reflected in the message 

length byte that precedes the base message string. It is 
essential that the base message string, and each optional 
argument string be followed by a Null terminator byte. 
There are some optional arguments that consist of a 

15 single ASCII character, and these too must be followed by 
the Null terminator byte. 

Since the message length byte that precedes a 
request message tells the HVR exactly how many additional 
20 bytes must be consumed from the Socket stream in order to 
obtain the request, that byte must reflect all of the 
strings and their associated Null terminators. Otherwise 
the HVR will not "consume" the entire message before 
attempting to interpret it. 

25 

The "Write to Stream" command is sent by the 
acquisition system as the first data on a successfully 
opened TCP/IP Socket Connection. This command consists 
of an upper or lower — case 'w', followed by the Stream 
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Name that v/as specified when the stream partition was 
allocated, followed by a zero value to terminate the 
Stream Name string. Note that the command must be 
preceded by the "count byte" as described above. 

5 

If the HVR processor finds this to be a valid 
Stream Name, it will reply with a single character 
response of 'G'. If there is a problem with the attempt 
to establish the "write" connection, one of several error 
10 responses will be sent. Once the acquisition client has 
received a 'G' response, it can begin to send data on the 
open socket connection stream. 

Optional arguments for the "Write to Stream" 
15 command are: "N" , for "No Wrap" mode, and "R" for "Reset 
Write Indices". Neither option takes any additional 
parameters . 

The "No Wrap" option causes the HVR to first 
20 reset the Write location to the start of the Partition 
before beginning to store any data, and also to stop 
writing to the specified Stream when the end of the 
Partition is reached. This is primarily useful in 
testing the integrity of a Partition. 

25 

The "Reset Indices" option causes the Write 
location to be reset to the start of the Partition before 
beginning to store any data. This does, however, allow 
writing to "Wrap" when the end of the Partition is 
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reached. This is also intended as a "test" feature. 



The "Read from Stream" command is sent by the 
acquisition system as the first data on a successfully 
5 opened TCP/IP Socket Connection. This command consists 
of an upper or lower case 'r' , followed by the Stream 
Name that was specified when the stream partition was 
allocated, followed by a zero value to terminate the 
Stream Name string. Note that the command must be 
10 preceded by the "count byte" as described above. 

If the HVR processor finds this to be a valid 
Stream Name, it will reply with a single character 
response of 'G'. If there is a problem with the attempt 
15 to establish the "read" connection, one of several error 
responses will be sent. Once the acquisition client has 
received a 'G' response, it can begin to read data from 
the open socket connection stream. 



20 Optional arguments for the "Read from Stream" 

command are: "N" , for "No Wrap" mode, "O" for specifying 
an "Offset" in Mbytes at which the Reading should begin, 
and "X" for specifying the total number of Mbytes to be 
sent by the HVR. 

25 

The "N" option is the counterpart of the "No 
Wrap" option that is available on the "Write to Stream" 
command. This option causes the HVR to begin reading at 
the top of the Partition, and stop reading when the end 
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of the Partition is reached. This is typically used to 
verify the content of a partition that was filled, for 
test purposes, using the "N" option on the "Write to 
Stream" operation. 

5 

The "o"" and "X" options are similar in that 
they are both followed by an ASCII — decimal value that 
represents a number in Mbytes. The "O" option represents 
a backwards offset, relative to the current Write 
10 location, at which the reading of data from the Partition 
is to begin. This is a positive value expressed in 
Mbytes . 



For example, an argument of "015" would back up 
15 by 15 Mbytes from the current Write location. That is, 
it would set the Read pointer back at the data that was 
stored 15 Mbytes ago. There are some constraints 
associated with this option. For example, if a value is 
specified which is larger than the Partition storage 
20 area, then the Read location remains at the current Write 
location. Also, if the Partition has not been "filled" 
since the last time the Write location was reset, then 
the offset will not be adjusted backwards beyond the top 
of the Partition. This is because data which "follows" 
25 the current Write location is meaningless. 
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The "Status Query on Stream" command is sent by 
the acquisition system as the first data on a 
successfully opened TCP/IP Socket Connection. This 
5 command consists of an upper or lower case 's', followed 
by the Stream Name that was specified when the stream 
partition was allocated, followed by a zero value to 
terminate the Stream Name string. Note that the command 
must be preceded by the "count byte" as described above. 

10 

If the HVR processor finds this to be a valid 
Stream Name, it will reply with a single character 
response of 'G'. If there is a problem with the attempt 
to establish the "status query" connection, one of 

15 several error responses will be sent. If the 'G' 

response is received, it will be followed by a "Status 
Response" message which conforms to the message format 
described for commands to the HVR. That is, the 
remainder of the response will consist of a "count byte" 

20 followed by a Null terminated string. The string will be 
of the form: "L:n T:n". 



Note that the quotes are NOT part of the 
response, but are shown to emphasize that the entire 
25 response is an ASCII, Null terminated string. The letter 
'n' indicates an ASCII decimal representation of the 
appropriate error count. The first 'n' value is the 
"Loop Error Count" and represents the number of write 
errors that occurred on the current pass through the 
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stream Partition. 



This value is cleared automatically at the 
start of each pass through the Partition's memory loop. 
5 The second 'n' represents the "Total Error Count", and is 
the accumulated number of errors since the counters were 
last cleared (manually or as a result of setting up the 
Partition Map) . 



10 The response to the 'W , 'R', or 'S' commands 

is a single ASCII character. There is no "count byte" or 
Null terminator. 



If the Partition Name is valid and access has 
15 been established, the response is a 'G' character. If 

the Partition Name is not recognized, the response is an 
'S' character. If the Partition has no devices allocated 
to it, the response is an 'E' character. If the 
Partition is busy (another client is already writing in 
20 the Partition), the response is a 'B' character. If the 
Partition is Out of Service for some other reason (failed 
devices, etc.), the response is an 'O' character. 



Note that the response to the ' S ' command is 
25 somewhat unique in that it follows the "single ASCII 
character" form, taut if a valid request was made, 
continues with a "full message" type of response. 
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The HVR allows only one Client to be writing to 
a particular Partition at a time. That is, only one 'W 
connection will be allowed for each in-service Partition. 
5 The HVR will also accept one or more 'R' connections for 
a Partition, even if there is currently an active 'W 
connection. Issues related to the effects of multiple 
connections on performance (system throughput) must be 
carefully considered. 

10 

The response to a 'W command, for a Partition 
that already has an active 'W connection, is the 'B' 
message (busy) . 

15 The current implementation of the HVR subsystem 

is capable of data transfer to or from the protected 
memory store at a rate of around 1.5 Mbits per second 
(using 10-Base T ETHERNET) . That is, a data acquisition 
host or hosts can send data to the protected memory 

20 store, or retrieve data from the store, at approximately 
this rate, when all other conditions are optimal. 



When sending data to the HVR, the maximum rate 
can only be achieved if at least three partitions are 
25 being written to concurrently. This is a consequence of 
the architecture of the memory devices being used in the 
protected memory store and the HVR software that manages 
the devices. That is, the maximum write rate relies on 
the HVR software being able to continuously manage 
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concurrent v/rites in multiple devices. 

There are essentially two buffers used to 
process the data. The first is the receipt of data 
5 packets into an incoming queue, the throughput of this 
process is approximately 1,5 Mbits per second. The 
second is in the processing of those data packets from 
the incoming queue to the flash devices, the throughput 
of this process is dependent on how the flash chips are 

10 managed/mapped. A write to a flash device is slow, 

relatively speaking, and the software must wait for a 
write to complete on a given chip before another write 
can begin. Therefore, if there is only one partition, 
the writes are all sequential and the throughput will 

15 slow to the rate of the chip write function (which can be 
chip and temperature dependent) . 

If however, there are multiple partitions, 
concurrent writes can occur because the software will be 

20 writing to different chips. This effectively increases 
the throughput by n times, where n is defined by the 
number of partitions. Since the throughput of the 
process to receive incoming data packets is approximately 
1.5 Mbits per second, the goal of the host computer is to 

25 partition the flash devices so that this rate can be 

achieved. Experimentation has shown at least three to 
four partitions are required. 
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The maximum read rate is also around 1.5 Mbits 
per second, assuming that there is no simultaneous 
writing. The rate of a chip read function is much faster 
5 than the write so even if there is only one read 

occurring (sequential access to a chip) it can keep up 
with the rate of the process to receive incoming data 
packets . 

10 When reading and writing are performed 

together, the available bandwidth of the HVR will be 
distributed between the operations in a manner that will 
vary depending on system dynamics. 



15 There have been described and illustrated 

herein a hardened voyage data recorder and an example of 
software for using the recorder over an ETHERNET network. 
While particular embodiments of the invention have been 
described, it is not intended that the invention be 

20 limited thereto, as it is intended that the invention be 
as broad in scope as the art will allow and that the 
specification be read likewise. In particular, the 
specific arrangement of web pages and the specific 
communications protocol described herein represent a 

25 presently preferred embodiment, but the invention is not 
limited thereto. 
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It will therefore be appreciated by those 
skilled in the art that yet other modifications could be 
made to the provided invention without deviating from its 
5 spirit and scope as so claimed. 
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